Description

The deb-package workflow installs nodejs from the runner’s default APT sources without ensuring it
meets the package dependency nodejs (>= 20), so dpkg -i can fail to configure (or behave
differently) depending on the runner image. This makes the smoke-test nondeterministic and can
invalidate the subsequent assertions/startup test.

Code

.github/workflows/deb-package.yml[R136-139]

+          set -eux
+          sudo apt-get update
+          sudo apt-get install -y nodejs
+          sudo dpkg -i dist/*.deb || sudo apt-get install -f -y

Evidence

The package explicitly requires Node.js >= 20, but the workflow installs whatever `apt-get install
nodejs` provides. The local packaging smoke test script adds NodeSource first, indicating the
default distro repository may not be sufficient and that a dedicated setup step is expected for
determinism.

.github/workflows/deb-package.yml[133-140]
packaging/nfpm.yaml[22-26]
packaging/test-local.sh[120-129]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The CI smoke test installs `nodejs` from default APT sources without ensuring it satisfies the package dependency (`nodejs (>= 20)`), making the smoke test nondeterministic and potentially invalid.
### Issue Context
- The `.deb` declares `Depends: nodejs (>= 20)`.
- The workflow currently does `apt-get install -y nodejs` with no repo setup/pinning.
- `packaging/test-local.sh` already uses NodeSource (`setup_lts.x`) before installing nodejs.
### Fix Focus Areas
- .github/workflows/deb-package.yml[136-139]
### Suggested fix
In the smoke-test step, install Node.js via a deterministic mechanism, for example:
- Add NodeSource LTS repo (`curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -`) then `sudo apt-get install -y nodejs`, **or**
- Use a pinned distro/repo that guarantees `nodejs >= 20`.
This should happen before `dpkg -i dist/*.deb` so the package can configure and `postinstall` assertions are meaningful.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The PR fixes run_cmd to reject on spawn errors (e.g. missing binary), but it does not add a
regression test to ensure this behavior doesn’t silently regress. Without an automated test, the
original process-killing failure mode could be reintroduced unnoticed.

Code

src/node/utils/run_cmd.ts[R149-159]

+  // Without this, a spawn failure (e.g. ENOENT for a missing binary) is
+  // emitted as an 'error' event with no listener, which Node.js treats as
+  // an uncaught exception that bypasses any try/catch around the awaited
+  // promise and kills the process. Reject the promise instead so callers
+  // can handle it.
+  proc.on('error', (err) => {
+    procFailedErr.message = `Failed to spawn ${args[0]}: ${(err as Error).message}`;
+    procFailedErr.code = (err as any).code;
+    logger.debug(procFailedErr.stack);
+    px.reject(procFailedErr);
+  });

Evidence

Compliance ID 1 requires bug fixes to include a regression test. The added proc.on('error', ...)
handler is explicitly a bug fix for unhandled spawn errors, but no corresponding test is
added/modified in this PR diff to validate the new rejection behavior.

src/node/utils/run_cmd.ts[149-159]
Best Practice: Repository guidelines

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A bug fix was added to `src/node/utils/run_cmd.ts` to handle `spawn` failures by rejecting the returned promise, but there is no regression test that would fail if this handler were removed.
## Issue Context
The new code handles the `ChildProcess` `error` event (e.g. `ENOENT`) and calls `px.reject(...)` instead of letting Node treat the unhandled `error` event as an uncaught exception that kills the process. Add a `vitest` test that calls `run_cmd()` with a definitely-missing binary name and asserts it rejects with an error that includes `code === 'ENOENT'` (or equivalent), ensuring the test suite would fail/crash if the handler were reverted.
## Fix Focus Areas
- src/node/utils/run_cmd.ts[149-159]
- src/tests/backend-new/specs/[add new test file exercising spawn ENOENT]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The preinstall maintainer script requires addgroup/adduser, but the package only declares adduser as
a regular dependency, so dpkg -i on a minimal system can fail before unpacking if adduser isn’t
already installed.

Code

packaging/scripts/preinstall.sh[R6-18]

+case "$1" in
+  install|upgrade)
+    if ! getent group etherpad >/dev/null 2>&1; then
+      addgroup --system etherpad
+    fi
+    if ! getent passwd etherpad >/dev/null 2>&1; then
+      adduser --system --ingroup etherpad \
+              --home /var/lib/etherpad \
+              --no-create-home \
+              --shell /usr/sbin/nologin \
+              --gecos "Etherpad service user" \
+              etherpad
+    fi

Evidence

preinstall.sh unconditionally executes addgroup/adduser under set -e. nfpm.yaml declares adduser
under depends, which is not sufficient to guarantee the binary exists before preinst runs in
direct dpkg -i flows (where dependencies are not pre-fetched/configured automatically).

packaging/scripts/preinstall.sh[1-18]
packaging/nfpm.yaml[22-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`preinstall.sh` calls `addgroup`/`adduser` during the `preinst` phase, but `adduser` is only in `Depends`. Direct installs via `dpkg -i` can run `preinst` before `adduser` is present, causing installation to abort.
### Issue Context
This is especially problematic because a `preinst` failure happens *before* unpacking, so follow-up dependency repair (`apt-get -f install`) may not be able to recover.
### Fix Focus Areas
Implement one of:
- **Debian-correct dependency**: add a Debian `Pre-Depends: adduser` (if nfpm supports it) so `adduser` is guaranteed before `preinst`.
- **Move user/group creation later**: shift user/group creation to `postinstall` (`configure`), and adjust packaging so unpack-time ownership does not require the `etherpad` group to already exist (e.g., set `/etc/default/etherpad` group to root in the payload and `chgrp` it in `postinstall`).
- packaging/scripts/preinstall.sh[1-18]
- packaging/nfpm.yaml[22-26]
- packaging/scripts/postinstall.sh[16-34]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

packaging/bin/etherpad starts Etherpad with Node’s ESM preload (--import …/tsx/…/esm/index.mjs), but
Etherpad’s production entrypoint expects the CommonJS tsx/cjs require hook and uses CommonJS
exports. This will likely crash at startup (exports is undefined) and prevent etherpad.service from
starting.

Code

packaging/bin/etherpad[R13-17]

+# Run the server through tsx's ESM loader (shipped in node_modules).
+# No pnpm needed at runtime.
+exec node \
+    --import "file://${APP_DIR}/src/node_modules/tsx/dist/esm/index.mjs" \
+    "${APP_DIR}/src/node/server.ts" \

Evidence

The wrapper preloads tsx’s ESM loader, but Etherpad’s own prod script uses tsx/cjs, and the server
entrypoint uses CommonJS-style exports (which are not available in ESM).

packaging/bin/etherpad[13-18]
src/package.json[144-151]
src/node/server.ts[107-116]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`/usr/bin/etherpad` preloads tsx via Node's `--import` pointing at tsx's ESM loader, but Etherpad's server entrypoint is started in CommonJS mode (`tsx/cjs`) and uses `exports.*`. This mismatch can break startup.
### Issue Context
Etherpad's own `src/package.json` uses `node --require tsx/cjs node/server.ts` for production. `src/node/server.ts` assigns `exports.start = ...`, which will throw if the file is evaluated as an ES module.
### Fix Focus Areas
- packaging/bin/etherpad[13-18]
### Suggested change
Switch to the CJS preload used by Etherpad:
- Replace `--import "file://.../tsx/.../esm/index.mjs"` with `--require tsx/cjs` (or an absolute path to `tsx/cjs` under the installed tree).
- Keep `NODE_ENV=production` as you already do.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The package installs /opt/etherpad as root:root and the systemd unit uses ProtectSystem=strict
without making Etherpad’s plugin install paths writable. Etherpad installs plugins into
/opt/etherpad/src/plugin_packages and creates symlinks under /opt/etherpad/src/node_modules, so
plugin installs/upgrades will fail with EACCES under the packaged service.

Code

packaging/systemd/etherpad.service[R23-44]

+NoNewPrivileges=true
+ProtectSystem=strict
+ProtectHome=true
+PrivateTmp=true
+PrivateDevices=true
+ProtectKernelTunables=true
+ProtectKernelModules=true
+ProtectKernelLogs=true
+ProtectControlGroups=true
+ProtectHostname=true
+ProtectClock=true
+RestrictRealtime=true
+RestrictSUIDSGID=true
+RestrictNamespaces=true
+LockPersonality=true
+MemoryDenyWriteExecute=false     # Node's JIT needs W+X mappings
+SystemCallArchitectures=native
+RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
+UMask=0027
+
+ReadWritePaths=/var/lib/etherpad /var/log/etherpad /etc/etherpad
+

Evidence

Etherpad’s plugin framework writes to settings.root/src/plugin_packages and creates symlinks in
settings.root/src/node_modules, but the package makes /opt/etherpad root-owned and the systemd
sandbox only allows writes to /var/lib/etherpad, /var/log/etherpad, and /etc/etherpad. The
postinstall script only redirects /opt/etherpad/var to /var/lib and does not address plugin paths.

packaging/nfpm.yaml[51-59]
packaging/systemd/etherpad.service[23-44]
src/node/utils/Settings.ts[301-305]
src/static/js/pluginfw/installer.ts[25-29]
src/static/js/pluginfw/LinkInstaller.ts[18-24]
src/static/js/pluginfw/LinkInstaller.ts[203-214]
packaging/scripts/postinstall.sh[40-50]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The packaged service cannot install/upgrade plugins at runtime because Etherpad's plugin manager writes to:
- `${settings.root}/src/plugin_packages`
- `${settings.root}/src/node_modules` (creates symlinks)
In the package, `${settings.root}` resolves to `/opt/etherpad`, which is installed as root:root and is read-only under `ProtectSystem=strict`.
### Issue Context
- `installer.ts` defines `pluginInstallPath` under `settings.root/src/plugin_packages` and `node_modules` under `.../src/node_modules`.
- `LinkInstaller` uses `PluginManager({pluginsPath: pluginInstallPath})` and symlinks into `node_modules`.
- `nfpm.yaml` sets `/opt/etherpad` tree owner/group to root:root.
- `etherpad.service` only allows writes to `/var/lib/etherpad`, `/var/log/etherpad`, `/etc/etherpad`.
- `postinstall.sh` currently only redirects `/opt/etherpad/var`.
### Fix Focus Areas
- packaging/systemd/etherpad.service[23-44]
- packaging/nfpm.yaml[51-59]
- packaging/scripts/postinstall.sh[40-50]
### Suggested fix approach
1) Redirect plugin storage to `/var/lib/etherpad` (similar to the existing `/opt/etherpad/var` redirect):
- Create `/var/lib/etherpad/plugin_packages` owned by `etherpad:etherpad`.
- Symlink `/opt/etherpad/src/plugin_packages -> /var/lib/etherpad/plugin_packages` in `postinstall.sh`.
2) Allow symlink creation under `/opt/etherpad/src/node_modules`:
- Add `/opt/etherpad/src/node_modules` to `ReadWritePaths=` in the unit, and
- In `postinstall.sh`, make that directory writable for the service user (e.g., `chgrp etherpad /opt/etherpad/src/node_modules && chmod g+w /opt/etherpad/src/node_modules`).
If runtime plugin installation is intentionally unsupported for the .deb, then explicitly disable/hide the plugin installer UI and document the limitation; otherwise users will hit runtime failures.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The deb-package workflow’s tag filters use regex-like patterns (v[0-9]+.[0-9]+.[0-9]+) but GitHub
Actions uses glob matching, where [0-9]+ is a single-character class (digit or '+'), not
“one-or-more digits”. As a result, common tags like v2.10.0 will not match and the workflow won’t
run.

Code

.github/workflows/deb-package.yml[R2-6]

+on:
+  push:
+    tags:
+      - 'v[0-9]+.[0-9]+.[0-9]+'
+      - 'v[0-9]+.[0-9]+.[0-9]+-*'

Evidence

The new workflow uses [0-9]+ sequences in the tag filters, but the repository’s existing release
workflow uses a standard glob (v*.*.*) which correctly matches multi-digit semver components. With
glob semantics, [0-9]+ matches exactly one character, so multi-digit segments (like 10) won’t
match.

.github/workflows/deb-package.yml[2-7]
.github/workflows/handleRelease.yml[4-8]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow tag filters are written like regex (`[0-9]+`), but Actions tag filters are globs. In a glob, `[0-9]+` matches a single character (a digit or '+'), so tags with multi-digit components (e.g., `v2.10.0`) won't trigger the workflow.
### Issue Context
There is already a correct pattern in `.github/workflows/handleRelease.yml`: `v*.*.*`.
### Fix Focus Areas
- .github/workflows/deb-package.yml[2-7]
### Suggested change
Replace the tag filters with glob patterns such as:
- `v*.*.*`
- `v*.*.*-*`
(or a single broader `v*` if you prefer and then validate/tag-parse inside the job).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

On fresh installs, Etherpad startup runs checkForMigration(), which falls back to running pnpm ls
and then writing /opt/etherpad/var/installed_plugins.json if the file is missing; the package does
not ship/create that file, and the systemd unit disallows writes under /opt/etherpad. This can
cause the service to crash during startup and never reach /health.

Code

.github/workflows/deb-package.yml[R73-85]

+      - name: Stage tree for packaging
+        run: |
+          set -eux
+          STAGE=staging/opt/etherpad
+          mkdir -p "${STAGE}"
+
+          # Production footprint = src/ + bin/ + node_modules/ + metadata.
+          cp -a src bin package.json pnpm-workspace.yaml README.md LICENSE \
+                node_modules "${STAGE}/"
+
+          # Make pnpm-workspace.yaml production-only (same trick Dockerfile uses).
+          printf 'packages:\n  - src\n  - bin\n' > "${STAGE}/pnpm-workspace.yaml"
+

Evidence

The packaging workflow stages only src/, bin/, root metadata, and node_modules/ into the
/opt/etherpad tree, so /opt/etherpad/var/installed_plugins.json is not present in the resulting
package. At runtime, Etherpad’s server startup always calls checkForMigration(), which runs `pnpm
ls if installed_plugins.json is missing and then writes the file under settings.root/var`; with
the packaged layout settings.root resolves to /opt/etherpad. The systemd unit uses
ProtectSystem=strict and only whitelists /var/lib/etherpad, /var/log/etherpad, and
/etc/etherpad as writable, so writing to /opt/etherpad/var is not permitted even if the
directory existed.

.github/workflows/deb-package.yml[73-85]
packaging/nfpm.yaml[47-59]
packaging/scripts/postinstall.sh[14-40]
packaging/systemd/etherpad.service[22-44]
packaging/bin/etherpad[13-18]
src/node/server.ts[151-176]
src/static/js/pluginfw/installer.ts[25-90]
src/static/js/pluginfw/installer.ts[122-148]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Fresh installs can fail because Etherpad calls `checkForMigration()` during startup, and if `/opt/etherpad/var/installed_plugins.json` is missing it tries to execute `pnpm ls` and write that file under `/opt/etherpad/var`. The .deb packaging currently doesn’t ship/create that file (or even `/opt/etherpad/var`), and the systemd unit doesn’t permit writes under `/opt/etherpad`.
### Issue Context
- Packaging stages `/opt/etherpad` from a curated file list.
- Etherpad’s plugin migration logic treats absence of `var/installed_plugins.json` as a trigger to run `pnpm` and then persist plugin state under `settings.root/var`.
- The systemd sandbox only allows writes to `/var/lib/etherpad`, `/var/log/etherpad`, and `/etc/etherpad`.
### Fix Focus Areas
- .github/workflows/deb-package.yml[73-85]
- packaging/nfpm.yaml[47-59]
- packaging/scripts/postinstall.sh[14-40]
- packaging/systemd/etherpad.service[22-44]
### Suggested fix approach
1. Ensure `/opt/etherpad/var/` exists in the packaged tree (or create it in `postinstall.sh`).
2. Seed `/opt/etherpad/var/installed_plugins.json` at install time with minimal valid content (for example, only `ep_etherpad-lite`), so `checkForMigration()` does not attempt to run `pnpm` on first boot.
3. If you want runtime plugin install/uninstall to work under the hardened unit, relocate plugin state to `/var/lib/etherpad` (and symlink `/opt/etherpad/var` to it), and/or extend `ReadWritePaths` to include the required writable plugin directories.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The unit sets ProtectSystem=strict but Etherpad writes runtime files under settings.root/var during
startup (for example var/js and var/installed_plugins.json). Because /opt/etherpad/var is neither
created/redirected in postinstall nor included in ReadWritePaths, a fresh install can fail to start
with mkdir/write errors under /opt/etherpad/var.

Code

packaging/systemd/etherpad.service[R22-44]

+# --- Sandboxing ---------------------------------------------------------
+NoNewPrivileges=true
+ProtectSystem=strict
+ProtectHome=true
+PrivateTmp=true
+PrivateDevices=true
+ProtectKernelTunables=true
+ProtectKernelModules=true
+ProtectKernelLogs=true
+ProtectControlGroups=true
+ProtectHostname=true
+ProtectClock=true
+RestrictRealtime=true
+RestrictSUIDSGID=true
+RestrictNamespaces=true
+LockPersonality=true
+MemoryDenyWriteExecute=false     # Node's JIT needs W+X mappings
+SystemCallArchitectures=native
+RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
+UMask=0027
+
+ReadWritePaths=/var/lib/etherpad /var/log/etherpad /etc/etherpad
+

Evidence

The service sandbox makes the filesystem read-only except for explicit exceptions, but Etherpad’s
startup path writes to <root>/var. With the Debian layout, Etherpad’s computed root is the directory
above src (so /opt/etherpad), making those writes target /opt/etherpad/var which is not writable per
the unit and not redirected by the packaging scripts.

packaging/systemd/etherpad.service[22-44]
packaging/scripts/postinstall.sh[34-40]
src/node/utils/AbsolutePaths.ts[77-93]
src/node/server.ts[173-175]
src/static/js/pluginfw/installer.ts[25-29]
src/static/js/pluginfw/installer.ts[136-148]
src/node/hooks/express/specialpages.ts[310-314]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The systemd unit makes `/opt/etherpad` effectively read-only (`ProtectSystem=strict` + `ReadWritePaths` omits `/opt/etherpad/...`), but Etherpad writes to `path.join(settings.root, 'var', ...)` during startup, where `settings.root` resolves to `/opt/etherpad` in this package layout. This can prevent `etherpad.service` from starting.
### Issue Context
Etherpad startup awaits `checkForMigration()` which can write `${root}/var/installed_plugins.json`, and the express hooks create `${root}/var/js`. The package currently does not create or redirect `/opt/etherpad/var` to a writable location.
### Fix Focus Areas
- packaging/scripts/postinstall.sh[34-40]
- packaging/systemd/etherpad.service[22-44]
### Suggested fix
Implement one of the following (prefer the symlink approach to keep writes out of `/opt`):
1) **Symlink `/opt/etherpad/var` to a writable location**:
- In `postinstall.sh` (configure):
- `mkdir -p /var/lib/etherpad/var`
- `ln -sfn /var/lib/etherpad/var /opt/etherpad/var`
- `chown -R etherpad:etherpad /var/lib/etherpad/var`
- This keeps `ReadWritePaths=/var/lib/etherpad` sufficient.
2) **Allow `/opt/etherpad/var` writes explicitly**:
- Create `/opt/etherpad/var` in `postinstall.sh` and `chown` it to `etherpad:etherpad`.
- Add `/opt/etherpad/var` to `ReadWritePaths` in the unit.
Either way, ensure the directory exists before service start so `fs.mkdirSync(.../var/js)` and plugin migration writes don’t throw.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

packaging/scripts/postremove.sh removes the /opt/etherpad symlinks only in the remove) case,
not in the purge) case. If postrm purge runs without the remove cleanup, /opt/etherpad can
be left behind containing dangling symlinks created by postinstall.sh.

Code

packaging/scripts/postremove.sh[R19-34]

+  purge)
+    rm -rf /etc/etherpad
+    rm -rf /var/lib/etherpad
+    rm -rf /var/log/etherpad
+
+    if getent passwd etherpad >/dev/null 2>&1; then
+      deluser --system etherpad >/dev/null 2>&1 || true
+    fi
+    if getent group etherpad >/dev/null 2>&1; then
+      delgroup --system etherpad >/dev/null 2>&1 || true
+    fi
+
+    if [ -d /run/systemd/system ] && command -v systemctl >/dev/null 2>&1; then
+      systemctl daemon-reload || true
+    fi
+    ;;

Evidence

postinstall.sh creates symlinks under /opt/etherpad (settings.json, var, and
src/plugin_packages). postremove.sh deletes those symlinks only for remove), but purge) only
deletes /etc and /var data and the user/group, leaving the symlinks unhandled in that branch.

packaging/scripts/postinstall.sh[36-50]
packaging/scripts/postinstall.sh[65-82]
packaging/scripts/postremove.sh[9-34]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `purge)` branch does not remove `/opt/etherpad` symlinks created during install, which can leave `/opt/etherpad` non-empty (and symlinks dangling).
### Issue Context
Symlinks are created in postinstall to expose `/etc/etherpad/settings.json` and redirect writable paths.
### Fix
In the `purge)` case, also remove the same symlinks as in `remove)` (or remove `/opt/etherpad` entirely if appropriate and safe).
### Fix Focus Areas
- packaging/scripts/postremove.sh[9-34]
- packaging/scripts/postinstall.sh[36-50]
- packaging/scripts/postinstall.sh[65-82]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The Debian smoke test installs NodeSource by piping a remote script directly into sudo bash,
executing network-fetched content as root during the workflow run. This increases the blast radius
of a supply-chain compromise of that endpoint to the job that builds and uploads release artifacts.

Code

.github/workflows/deb-package.yml[R141-142]

+          curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
+          sudo apt-get install -y nodejs

Evidence

The workflow explicitly downloads and executes a remote script as root via a pipe, without any
in-workflow signature/fingerprint verification step.

.github/workflows/deb-package.yml[133-143]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow executes `curl ... | sudo bash -` to install Node.js, which runs network content as root.
### Issue Context
This happens in the smoke test job before installing the newly built `.deb`.
### Fix Focus Areas
- .github/workflows/deb-package.yml[133-143]
### Suggested fix
Prefer a repository-based installation with explicit keyring + signed-by configuration (or a pinned, checksum-verified installer artifact) rather than piping to `bash`. For example:
- Fetch the NodeSource GPG key into `/usr/share/keyrings/nodesource.gpg` and configure the apt source with `signed-by=...`, then `apt-get update && apt-get install nodejs`.
- Alternatively, run the smoke test in a container image that already contains Node >=20 (to avoid installing Node via shell pipe at all).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The nfpm manifest claims the same packaging manifest can produce RPMs (and includes rpm-specific
dependency overrides), but the install/remove scripts call Debian-only user/group management
commands (addgroup/adduser/deluser/delgroup), so an RPM install would fail at script execution time.

Code

packaging/nfpm.yaml[R104-120]

+scripts:
+  preinstall:  ./packaging/scripts/preinstall.sh
+  postinstall: ./packaging/scripts/postinstall.sh
+  preremove:   ./packaging/scripts/preremove.sh
+  postremove:  ./packaging/scripts/postremove.sh
+
+overrides:
+  deb:
+    depends:
+      - nodejs (>= 20)
+      - adduser
+      - ca-certificates
+  rpm:
+    depends:
+      - nodejs >= 20
+      - shadow-utils
+      - ca-certificates

Evidence

The repo explicitly documents multi-packager output and configures rpm dependencies, but the
referenced scripts use Debian-specific commands and there are no rpm-specific script overrides,
creating an internal inconsistency that breaks RPM installation.

packaging/README.md[1-5]
packaging/nfpm.yaml[104-120]
packaging/scripts/preinstall.sh[6-18]
packaging/scripts/postremove.sh[19-30]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`packaging/nfpm.yaml` declares RPM support (and RPM dependencies), but the lifecycle scripts are Debian-specific (`addgroup/adduser/deluser/delgroup`). If someone builds an RPM from this manifest, installation/removal will fail when those commands are missing.
### Issue Context
The README also states the same manifest produces `.rpm`/`.apk`, which further implies this path is intended to work.
### Fix Focus Areas
- packaging/nfpm.yaml[104-120]
- packaging/scripts/preinstall.sh[6-18]
- packaging/scripts/postremove.sh[19-30]
- packaging/README.md[1-5]
### Suggested fix options
1) **If RPM/APK is in-scope:**
- Add per-packager script overrides (RPM equivalents using `groupadd/useradd/userdel/groupdel` from `shadow-utils`), and adjust systemd unit install path if needed for RPM-based distros.
2) **If Debian-only for now:**
- Remove/disable the RPM/APK claims in `packaging/README.md` and remove the `overrides.rpm` block (or clearly document Debian-only support) to avoid shipping a manifest that advertises broken RPM support.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The release workflow downloads an nfpm .deb via curl and installs it with dpkg without verifying a
checksum or signature. If the upstream artifact is tampered with, the workflow could produce
compromised release packages.

Code

.github/workflows/deb-package.yml[R64-71]

+      - name: Install nfpm
+        run: |
+          set -e
+          NFPM_ARCH=amd64
+          [ "${{ matrix.arch }}" = "arm64" ] && NFPM_ARCH=arm64
+          curl -fsSL -o /tmp/nfpm.deb \
+            "https://github.com/goreleaser/nfpm/releases/download/${NFPM_VERSION}/nfpm_${NFPM_VERSION#v}_${NFPM_ARCH}.deb"
+          sudo dpkg -i /tmp/nfpm.deb

Evidence

The workflow directly installs a remotely fetched .deb into the runner without any integrity
verification step (checksum/GPG).

.github/workflows/deb-package.yml[64-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow installs nfpm from a downloaded `.deb` without any integrity verification.
### Issue Context
Even with HTTPS, this lacks defense-in-depth against compromised upstream release artifacts.
### Fix Focus Areas
- .github/workflows/deb-package.yml[64-71]
### Suggested fix
Add an integrity verification step before `dpkg -i`, for example:
- Download nfpm’s published `checksums.txt` (or equivalent) for `${NFPM_VERSION}` and verify `/tmp/nfpm.deb` with `sha256sum -c`.
- Alternatively, verify a published signature (GPG/cosign) if available for nfpm release artifacts.
- Only proceed to `sudo dpkg -i` if verification passes.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In .github/workflows/deb-package.yml, the “Resolve version” step runs node -p ... before
actions/setup-node, so the workflow can fail on runners without a suitable preinstalled node
binary. This breaks packaging builds on non-tag pushes/PRs where VERSION is derived from
package.json.

Code

.github/workflows/deb-package.yml[R58-77]

+      - name: Resolve version
+        id: v
+        run: |
+          if [ "${GITHUB_REF_TYPE}" = "tag" ]; then
+            VERSION="${GITHUB_REF_NAME#v}"
+          else
+            VERSION="$(node -p "require('./package.json').version")"
+          fi
+          echo "version=${VERSION}" >>"$GITHUB_OUTPUT"
+          echo "Packaging version: ${VERSION}"
+
+      - uses: pnpm/action-setup@v6
+        with:
+          version: 10
+
+      - name: Setup Node
+        uses: actions/setup-node@v6
+        with:
+          node-version: '24'
+          cache: pnpm

Evidence

The workflow calls node -p &quo...

Clean up config, data, and system user on purge

packaging/scripts/postremove.sh

Define nfpm manifest for .deb package structure

packaging/nfpm.yaml

CLI wrapper launching Etherpad via tsx ESM loader

packaging/bin/etherpad

Hardened systemd unit with security restrictions

packaging/systemd/etherpad.service

Environment variable defaults for systemd service

packaging/systemd/etherpad.default

Document packaging layout, build, install, and upgrade

packaging/README.md

CI workflow to build, test, and release .deb packages

.github/workflows/deb-package.yml